<html>
<head><meta charset="utf-8"><title>deferencable attribute  #66600 · t-compiler/wg-llvm · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/index.html">t-compiler/wg-llvm</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html">deferencable attribute  #66600</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="181289281"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181289281" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181289281">(Nov 21 2019 at 09:51)</a>:</h4>
<p>Hey there <span class="user-mention" data-user-id="120791">@RalfJ</span> , I realized maybe i'd be better off having dialogue here rather than via <a href="https://github.com/rust-lang/rust/issues/55005#issuecomment-556978967" target="_blank" title="https://github.com/rust-lang/rust/issues/55005#issuecomment-556978967">github comments</a>. :)</p>



<a name="181289385"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181289385" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181289385">(Nov 21 2019 at 09:52)</a>:</h4>
<p>(that is, I think you and I are skimming the same LLVM PR's and/or email threads at the moment, such as <a href="https://reviews.llvm.org/D61652" target="_blank" title="https://reviews.llvm.org/D61652">LLVM D61652 "Introduce dereferenceable_globally"</a>, so maybe its easiest to discuss live)</p>



<a name="181289510"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181289510" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181289510">(Nov 21 2019 at 09:54)</a>:</h4>
<p>(Also, it does look like they landed <a href="https://reviews.llvm.org/D49165" target="_blank" title="https://reviews.llvm.org/D49165">nofree in D49165</a>?)</p>



<a name="181289799"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181289799" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181289799">(Nov 21 2019 at 09:59)</a>:</h4>
<p>One concern Ralf raised in the past is that <code>nofree</code> and <code>nosync</code> are function attributes, so if a function frees <em>any</em> memory (e.g. because it creates a temporary Vec internally) or synchronizes with anything (e.g. because it may panic, which involves at least some atomics to access the panic hook unless it's a no_std binary), no <code>dereferenceable</code> information for any pointer can be propagated across calls to it. My gut feeling is to agree that could potentially cause quite some regressions.</p>



<a name="181289830"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181289830" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181289830">(Nov 21 2019 at 09:59)</a>:</h4>
<p>I <em>just</em> noticed that point in the comment history. :)</p>



<a name="181290002"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290002" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290002">(Nov 21 2019 at 10:02)</a>:</h4>
<p>Still, I don't really understand the argument being made here. That is: I can understand making the argument "the model you are adopting is not as expressive as it could be."</p>



<a name="181290022"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290022" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290022">(Nov 21 2019 at 10:02)</a>:</h4>
<p>but that statement should not imply "it will regress performance from what we have today", as long as the future model is <em>at least</em> as expressive as today's model</p>



<a name="181290058"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290058" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290058">(Nov 21 2019 at 10:03)</a>:</h4>
<p>The only way I can see it regressing performance (and maybe this is what you all are in fact saying) is that if they <em>fix</em> bugs in the existing optimizations via relying on these additional attributes</p>



<a name="181290083"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290083" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290083">(Nov 21 2019 at 10:03)</a>:</h4>
<p>i.e. that we are today relying on optimizations that are themselves unsound (or that we are generating code that is generally-incorrectly attributed, and that code is then optimized)</p>



<a name="181290190"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290190" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290190">(Nov 21 2019 at 10:05)</a>:</h4>
<p>So is that the explanation for where the expected performance regressions would come from? Or am I misunderstanding?</p>



<a name="181290361"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290361" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290361">(Nov 21 2019 at 10:08)</a>:</h4>
<p>okay I now think I see how it all fits together</p>



<a name="181290385"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290385" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290385">(Nov 21 2019 at 10:08)</a>:</h4>
<p>It depends a bit on how the old <code>dereferenceable</code> attribute on function parameters is interpreted. If (as we generally did in the past) it means "dereferenceable for the duration of this function", that is something that's generally sound for e.g. Rust references passed as parameters (at least if there's no interior mutability) but can't be expressed in the future model. The new <code>dereferenceable</code> won't assert as much as it previously did due to nosync and nofree not being as precise (see above), and <code>dereferenceable_globally</code> is too strong (the referent can be deallocated after the function returns).</p>



<a name="181290406"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290406" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290406">(Nov 21 2019 at 10:08)</a>:</h4>
<p>okay yes, thanks for spelling that out</p>



<a name="181290414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290414">(Nov 21 2019 at 10:08)</a>:</h4>
<p>If on the other hand "the old <code>dereferenceable</code>" was supposed to mean what's now <code>dereferenceable_globally</code> then our usage of <code>dereferenceable</code> was always incorrect.</p>



<a name="181290712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290712">(Nov 21 2019 at 10:13)</a>:</h4>
<p>Am I right in thinking that what we may want is something like the <code>derefenceable_in_scope</code> semantics (perhaps in its own dedicated attribute), described <a href="https://reviews.llvm.org/D61652#1502431" target="_blank" title="https://reviews.llvm.org/D61652#1502431">here</a> ?</p>



<a name="181290797"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290797" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290797">(Nov 21 2019 at 10:14)</a>:</h4>
<p>or maybe I've misunderstood how the patch developed over time</p>



<a name="181290842"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290842" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290842">(Nov 21 2019 at 10:15)</a>:</h4>
<p>in any case, I think I am now semi-convinced that <span class="user-mention" data-user-id="120791">@RalfJ</span> was not wrong to raise a concern on that thread</p>



<a name="181290934"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181290934" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181290934">(Nov 21 2019 at 10:16)</a>:</h4>
<p>It seems like that is what we would want, but LLVM folks had concerns about whether those semantics can be implemented soundly (while still being useful for optimizations) so the patch changed to <code>dereferenceable_globally</code>.</p>



<a name="181291192"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291192" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291192">(Nov 21 2019 at 10:21)</a>:</h4>
<p>Ah, but after digging out the old diff, I see it tried to be clever about defining the attribute in such a way that it can apply to a region <em>within</em> a function. That's generally always very hard to do correctly (&amp; in a way that plays nicely with other transformations). Defining that's tied to function scope and dropped when inlining/outlining/etc. is much easier and would get us at least some fraction of the potential optimizations.</p>



<a name="181291210"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291210" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291210">(Nov 21 2019 at 10:21)</a>:</h4>
<p>So our running assumption is that the "new" interpretation of the <code>deferenceable</code> attribute is going to be "this is dereferenceable on function entry alone", and it will be up to LLVM analyses to determine how that affects the rest of the body?</p>



<a name="181291274"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291274" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291274">(Nov 21 2019 at 10:22)</a>:</h4>
<p>Yes</p>



<a name="181291341"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291341" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291341">(Nov 21 2019 at 10:23)</a>:</h4>
<p>And FWIW it's defined in a way that we can also translate e.g. <code>let x: &amp;T = foo();</code> to a <code>call</code> with <code>dereferenceable</code> attribute <em>on the return value</em> and that means the returned pointer is dereferenceable when it's returned (and analyses can try to figure out how long this holds from that point onward).</p>



<a name="181291748"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291748" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291748">(Nov 21 2019 at 10:27)</a>:</h4>
<p>yeah, I now see the overall problem. I had thought on my initial reading that the <code>no-free</code> attribute was specified on a parameter to a function, not as a property of the function as a whole</p>



<a name="181291846"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181291846" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181291846">(Nov 21 2019 at 10:28)</a>:</h4>
<p>(and that <code>no-free</code> would mean something like "the data pointed at by the parameter is not freed during the function's invocation.")</p>



<a name="181580346"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181580346" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181580346">(Nov 21 2019 at 20:20)</a>:</h4>
<blockquote>
<p>yeah, I now see the overall problem. I had thought on my initial reading that the <code>no-free</code> attribute was specified on a parameter to a function, not as a property of the function as a whole</p>
</blockquote>
<p>hmm, LLVM dev <a href="https://reviews.llvm.org/D61652#1755299" target="_blank" title="https://reviews.llvm.org/D61652#1755299">jdoerfert's response</a> to <span class="user-mention" data-user-id="120791">@RalfJ</span> leads me to think that my original interpretation was correct...? That is, no-free is a property on a parameter, not necessarily the function definition as a whole?</p>



<a name="181584801"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181584801" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181584801">(Nov 21 2019 at 21:11)</a>:</h4>
<p>That is also my reading of that comment, but the nofree patch I'm aware of (<a href="https://reviews.llvm.org/D49165" target="_blank" title="https://reviews.llvm.org/D49165">https://reviews.llvm.org/D49165</a>) explicitly defines it as a function attribute. Perhaps there was another patch?</p>



<a name="181584900"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181584900" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181584900">(Nov 21 2019 at 21:12)</a>:</h4>
<p>Yes, seems so: <a href="https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136" target="_blank" title="https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136">https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136</a></p>



<a name="181585046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181585046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181585046">(Nov 21 2019 at 21:14)</a>:</h4>
<p><a href="https://reviews.llvm.org/D67886" target="_blank" title="https://reviews.llvm.org/D67886">https://reviews.llvm.org/D67886</a></p>



<a name="181637136"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181637136" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181637136">(Nov 22 2019 at 13:29)</a>:</h4>
<blockquote>
<p>Yes, seems so: <a href="https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136" target="_blank" title="https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136">https://github.com/llvm/llvm-project/blob/44fe1f024d542bb7d286f9dd03ef35ad474399bd/llvm/docs/LangRef.rst#L1136</a></p>
</blockquote>
<p>I'm not an expert in reading these docs. What does this imply if the argument points to aliased memory? I.e. if I take two pointer parameters <code>x</code> and <code>y</code>, and I mark <code>x</code> nofree, but then I do free <code>y</code>?</p>



<a name="181637198"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181637198" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181637198">(Nov 22 2019 at 13:30)</a>:</h4>
<p>My hope/intuition is that writing such code and then passing the same pointer for <code>x</code> and <code>y</code> is a violation of the contract of <code>nofree</code></p>



<a name="181638604"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181638604" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181638604">(Nov 22 2019 at 13:49)</a>:</h4>
<p>Yes, that seems pretty clear-cut to me. The attribute asserts (implied: under threat of UB) that the memory pointed to by <code>x</code> is not freed by the callee, so any execution where that memory is freed is UB, no matter what pointer was used to free it.</p>



<a name="181639947"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181639947" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181639947">(Nov 22 2019 at 14:03)</a>:</h4>
<p>yeah I am confused now, too... <code>nofree</code> has all the same scope issues as <code>dereferencable_in_scope</code>, one would think</p>



<a name="181639955"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181639955" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181639955">(Nov 22 2019 at 14:03)</a>:</h4>
<p>I haven't had time to take another look at this</p>



<a name="181641478"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181641478" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181641478">(Nov 22 2019 at 14:18)</a>:</h4>
<p>I don't think it's comparable. For reference, the proposed definition of <code>dereferenceable_in_scope</code> was:</p>
<blockquote>
<p>This indicates that the annotated pointer value has the <code>dereferenceable(&lt;n&gt;)</code> property <em>at any program point</em> in its scope (as defined by the SSA dominance property). Thus, unlike pointer values annotated with <code>dereferenceable(&lt;n&gt;)</code>, <code>dereferenceable_in_scope(&lt;n&gt;)</code> pointer values can never lose the <code>dereferenceable(&lt;n&gt;)</code> property as long as the annotated value is accessible as an SSA value.</p>
</blockquote>
<p>This is problematic because it's very easy and common to expand the dominance region of values (even if you're not even looking at that value at the moment), and it's not natural or expected that this would have any repercussions. An attribute tied specifically to function boundaries, on the other hand, only requires care when changing function boundaries, which is a concern for far fewer transformations. It's also mechanically easier to ensure you drop the attribute when it becomes invalid (e.g. when inlining, you're replacing uses of the parameter anyway, so you'd have to go out of your way to introduce a bug by putting a new attribute on the value you're replacing it with).</p>



<a name="181651232"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181651232" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181651232">(Nov 22 2019 at 16:04)</a>:</h4>
<p>ah, so <code>nofree</code> only works on function parameters... but then one could do that for <code>dereferncable_in_scope</code> as well?</p>



<a name="181652587"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181652587" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181652587">(Nov 22 2019 at 16:17)</a>:</h4>
<p>Yes, I even mused about that possibility earlier in this thread. But if <code>nofree</code> + <code>dereferenceable</code>-at-entry is sufficient (is it? I'm not sure) why introduce yet another attribute?</p>



<a name="181661002"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181661002" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181661002">(Nov 22 2019 at 17:46)</a>:</h4>
<p>not sure if it is... concurrency is another concern</p>



<a name="181661030"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181661030" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181661030">(Nov 22 2019 at 17:47)</a>:</h4>
<p>inserting spurious writes that you can prove would happen anyway later would not be allowed because they might introduce a race</p>



<a name="181661044"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181661044" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181661044">(Nov 22 2019 at 17:47)</a>:</h4>
<p>moving reads around might turn them from non-racy to racy thus returning wrong results</p>



<a name="181662395"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181662395" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181662395">(Nov 22 2019 at 18:00)</a>:</h4>
<p>And there's not really a good way to use <code>nosync</code> to fix that, is implied? That seems plausible. nosync is kinda "all or nothing" (not per-pointer) and we can't apply it to most functions.</p>



<a name="181665689"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181665689" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181665689">(Nov 22 2019 at 18:40)</a>:</h4>
<p>well I thought <code>nofree</code> was global</p>



<a name="181665709"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181665709" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181665709">(Nov 22 2019 at 18:41)</a>:</h4>
<p>IOW, <code>nosync</code> could be per-ptr, too... ah but that won't help, it could be other ptrs doing the sync</p>



<a name="181715262"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181715262" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181715262">(Nov 23 2019 at 13:08)</a>:</h4>
<p>For <code>&amp;T</code> references without interior mutability, shouldn't the <code>noalias readonly</code> we add ensure that there are no writes (from any thread, least of all another) for the duration of the function? That won't help for <code>&amp;mut T</code>, but for those, both hoisting loads and spurious writes generally requires aliasing information (again: no intervening accesses from <em>any</em> thread, including the current one) in addition to dereferenceability.</p>



<a name="181820655"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187780-t-compiler/wg-llvm/topic/deferencable%20attribute%20%20%2366600/near/181820655" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/187780-t-compiler/wg-llvm/topic/deferencable.20attribute.20.20.2366600.html#181820655">(Nov 25 2019 at 13:12)</a>:</h4>
<p>hm, that sounds right, yes</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>